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(57) Abstract: A master controller (28) in a control area network system in a larger control area network (1 6, 1 8) may have a plurality 
of devices (33) coupled thereto. The master controller may further include a device manager (51) which provides a virtual device 

(58) . The virtual device operates to fink a state associated with the virtual device to a plurality of states associated with the devices 
such that the respective states are maintained in a substantially similar condition. The substantially similar condition is maintained 
by propagating a change in the state of the virtual device to a change in the state of the devices and a change in the state of one or 
more of the devices is propagated to the virtual device and all other devices. 
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METHOD AND SYSTEM FOR OPERATING VIRTUAL 

j 

DEVICES BY MASTER CONTROLLERS IN A CONTROL SYSTEM 

RELATED APPLICATIONS 

This patent application is related to co-pending U.S. applications entitled METHOD AND 
SYSTEM FOR MASTER TO MASTER COMMUNICATION IN CONTROL SYSTEMS, Serial No. 
09/328,926, filed June 9, 1999; and METHOD FOR DYNAMICALLY UPDATING MASTER 
5 CONTROLLERS IN A CONTROL SYSTEM, Serial No. 09/328,885, filed June 9, 1 999. 

TECHNICAL FIELD OF THE INVENTION 

This invention relates generally to control systems and more particularly to a method and system 
for operating virtual devices by a master controller in a control system. 

10 

BACKGROUND OF THE INVENTION 

Through the use of a control system, various equipment or appliances in an environment, such as 
a home or business, can be computer-controlled to form an automated environment The controlled 
equipment may include heating, ventilation and air conditioning (HVAC) systems, lighting systems, 

1 5 audio-visual systems, telecommunications systems, security systems, surveillance systems, and fire 

protection systems, for example. The equipment may be coupled to equipment controlling devices that 
are linked to a computer-based master controller through the use of a control area network. One or more 
user interface devices, such as a touch panel, may also be linked to the control area network to accept 
user input and display current system status. 

20 Traditional control systems typically have no or limited support for grouping a plurality of 

devices. The limited support provided by the traditional control systems have required unstable 
workarounds in order to group the behavior of the devices. 

SUMMARY OF THE INVENTION 

25 From the foregoing, it may be appreciated that a need has arisen for a method and system for 

operating virtual devices by a master controller in a control area network. 

In one aspect of the invention a system is provided to address this need, and involve a roaster 
controller and a plurality of devices coupled to the master controller, each of the devices having a 



1 



WO 00/75903 



PCT/US00/15762 



respective state associated therewith, and wherein each respective state represents a plurality of data 
values associated with the respective device. This aspect further involves a device manager associated 
with the master controller. In addition, this aspect involves a virtual device associated with the device 
manager and a set of the devices. The virtual device has a virtual device state associated therewith and 
5 the virtual device state represents a plurality of data values associated with the virtual device. The 
virtual device links the virtual device state and the respective states associated with the set of devices 
such that the virtual device state and the respective device states are maintained in a substantially similar 
condition. 



10 BRIEF DESCRIPTION OF THE DRAWINGS 

A better understanding of the present invention will be realized from the detailed description 
which follows, taken in conjunction with the accompanying drawings, in which: 

FIGURE 1 is a block diagram of an exemplary configuration of control area networks utilizing 
the present invention; 

1 5 FIGURE 2 is a detailed block diagram of a master controller according to an embodiment of the 

teachings of the present invention; 

FIGURE 3 is a detailed block diagram of a virtual device according to an embodiment of the 
teachings of the present invention; 

FIGURE 4 is a flow chart showing a method for routing data between a plurality of the master 
20 controllers according to an embodiment of the teachings of the present invention; 

FIGURE 5 is a flowchart showing a method for operating virtual elements by a master controller 
in a control area network according to an embodiment of the teachings of the present invention; and 

FIGURE 6 is a flowchart showing a method for dynamically updating a master controller in a 
control area network according to an embodiment of the teachings of the present invention. 

25 

DETAI1,F.D DESCRIPTION OF THE INVENTION 

Control area networks may be used to replace the typical discrete systems used to control items 
in a home or business. Traditionally, hems such as light fixtures and VCRs have been separately and 
manually controlled by light switches and individual remote controls. The present invention replaces 
30 such traditional systems with integrated, electronic control area networks to control items in a home or 
business. 
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FIGURE 1 is a block diagram showing an exemplary configuration of control area networks 
utilizing the present invention. A distributed control area network configuration 10, in the disclosed 
embodiment, includes a first control area network 16 and a second control area network 1 8. in another 
embodiment of the present invention, first and second control area networks 1 6 and 1 8 form a single 
5 control area network. First control area network 16 includes a plurality of control area network systems 
21, 23, and 26 ("CAN systems"). 

Each CAN system 2 1 , 23, and 26 includes a master controller 28 (respectively, 28A, 28B and 
28C) which are described in more detail in association with FIGURE 2. Master controller 28 refer to a 
generic master controller, while 28A-C refer to specific master controllers. In one embodiment, one 

1 0 master controller defines one CAN system. Stated another way, mere exists a one-to-one 

correspondence between CAN systems and master controllers. Each CAN system 21, 23 and 26 further 
has associated therewith a system identifier 27. System identifier 27 is used to uniquely identify each 
CAN system in a particular control area network. The system identifier may be any value or reference 
suitable to represent distinct systems, for example, integers, floating point numbers and character strings. 

15 In one embodiment, system identifier 27 is a numeric value which may be derived from an identifier 
associated with the respective master controller 28A-C. A system identifier is unique with respect to a 
control area network, but may be reused by a different control area network. 

In order to provide a clearer understanding of the present invention, an example is provided. 
Referring to FIGURE 1, CAN systems 21, 23 and 26 may respectively control three rooms in a house, 

20 specifically a living room, a kitchen and a bedroom. Various associated externa] devices 34 are 

controlled using the CAN systems. In particular, referring to the device and system numbers shown in 
FIGURE 1, device 1:1 (hereinafter, a particular device will be referred to as "device A:B W where A is the 
device number and B is the system number, i.e. device 1:1 is device 1 coupled to master controller 1) 
controls a security alarm panel and device 2:1 controls a TV, both in the living room. Device 1 :2 is a 

25 microwave oven and device 2:2 controls a light switch, both in the kitchen. Device 1 :3 controls a VCR 
and device 2:3 controls an alarm clock, both in the bedroom. 

A respective hub 3 1 may be coupled to each master controller 28. In the disclosed embodiment, 
hub 3 1 is shown as being separate from master controller 28, however, hub 3 1 may be integral to master 
controller 28. A plurality of devices may be coupled to master controller 28 through hub 3 1 . 

30 In one embodiment, devices 33 are slave devices which require coupling to master controller 28 

for proper operation, however, various level of intelligence and capability may be included with devices 
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33 that may require various levels of control and interaction with master controller 28 for proper 
operation. Each device 33 has a device number 32 used to uniquely identify each device 33 in a 
particular CAN system (such as 21, 23 and 26). Device numbers 32 may be any vaJue or reference 
suitable to represent distinct devices, for example, integers, floating point numbers and character strings. 
5 In addition, device numbers 32 are unique within a single CAN system (such as 21 , 23 and 26), but may 
be reused within different CAN systems. 

Each device 33 further includes a plurality of ports 35, a plurality of levels (not shown), and a 
plurality of channels (not shown). Ports 35, levels and channels may be used to communicate with one 
or more associated external devices 34 controlled by device 33. Devices 33 used to control associated 

1 0 external devices 34 may include infrared emitters, light switches, touch pads, and direct connections to 
associated external devices 34. For example, associated external devices 34 may include VCRs, TVs, 
stereo systems, infrared remote controllers, and lights. 

Each master controller 28 may be coupled to one or more other master controllers 28 by an 
intramaster link 36A, 36B and 36C. For example, master controller 28A is coupled to master controller 

15 28B by intramaster link 36A. Intramaster links 36A-C may be Ethernet links, AXLinks links, LONTalk 
links, Wide Area Network links, Local Area Network links, FTP links, Internet links, fiberoptic 
and other suitable combinations of electrical, physical and logical communication systems. Intramaster 
links 36A-C may be used to couple one master controller 28A to another master controller or controllers 
28B-C that exist in the same or different control area networks (such as 16 and 18) or between different 

20 CAN systems (such as 2 1 , 23 and 26). In the disclosed embodiment, intramaster link 36C couples first 
control area network 16 to second control area network 1 8 over the Internet 43, while other intramaster 
links 36A-B couple master controllers 28A-C within a single control area network 16. 

Second control area network 18 includes at least one CAN system 38 and a master controller 
28D. Second control area network 18 may be configured similarly to first control area network 16 or in 

25 any other suitable way and is shown in one embodiment with exemplary master controller 28D. 

Continuing the previous example, CAN system 38 may represent a security service for home protection. 
The security service may remotely control the various devices in the home in order to provide increased 
security when a home owner is out of town. More specifically, a home owner sets the alarm clock in the 
bedroom to awaken the home owner for a business trip. Master controller 3 (28C) then commands 

30 master controller 1 (28A) to activate the TV and set the TV channel to the morning news. After a 
predetermined delay, such as the amount of time normally spent in the shower by the home owner, 
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master controller 3 (28C) will send a further command to master controller 2 (28B) and request that the 
lights in the kitchen be turned on so that the homeowner can prepare breakfast After breakfast the 
homeowner activates the security alarm using the security alarm panel in the living room and leaves the 
house. In response to the activation of the security alarm, master controller 1 (28A) turns off the TV 
5 using device 1 : 1 (which master controller 1 (28A) has direct control over) and requests master controller 
3 (28C) to turn off the lights in the kitchen with device 2:2. Master controller 1 (28A) then sends a 
further command to the security service of CAN system 38 informing the security service that the house 
will be empty for the duration of the business trip. Master controller (28D) of the security service may 
then send out commands requesting that the various master controllers in the home turn on lights, stereo 

1 0 systems, and TVs to simulate the presence of a person in the house in order to deter crime. 

A plurality of content providers 46 may be accessed by master controllers 28A-D over links 
36A-C. Content providers 46 may include any of the well-known providers of information on the 
Internet 43 and, in particular, may also include a company web site which may provide upgrades, 
enhancements, and other information used to update or modify software or firmware on master controller 

15 28. A web browser 48 may be used to manipulate and control master controllers 28A-D from a remote 
location over the Internet 43. 

FIGURE 2 is a block diagram showing details of master controller 28. Each master controller 28 
includes a device manager 51, a connection manager 53, a message dispatcher 56, a TCP/IP stack 79 and 
firmware 57. Each of device manager 51, connection manager 53, message dispatcher 56, and firmware 

20 57 is described only for one exemplary master controller 28, but applies to any particular master 
controller 28A-D. 

Device manager 51 maintains status information about each device 33 coupled to master 
controller 28. The status information maintained by device manager 51 includes port information, string 
information, command information, and maintenance information. 

25 The port information includes a port count for each device 33, indicating the number of ports 35 

(Figure 1) supported by each device 33. Each port 35 may include one or more channels and one or 
more levels. The channels further include input channels and output channels and the levels further 
include input levels and output levels. Channel information and level information is further respectively 
maintained for each channel and level of each port on each device 33. The channel information 

30 maintains the status of each input channel and each output channel on the port. In the disclosed 

embodiment, the channel information may include information for 255 input channels and 255 output 
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channels associated with each port 35, but device 33 may specify a different number of channels. Also, 
each channel may be in either an on or an off state, or may represent a single binary value, for example, 
high or low, and 0 or 1, respectively. The channels may be used as flags to represent various information 
about device 33. In the disclosed embodiment, device 33 will inform device manager 5 1 of the number 
5 of channels supported by each port 35 on that device 33 when device 33 is activated, reset or turned on. 
Device 33 may also inform device manager 51 at a different time or change the number of supported 
channels dynamically. 

The level information maintained by device manager 51 may be used to specify a value within a 
range of allowed values associated with each port 35, as opposed to the channel information which tracks 

1 0 binary value information. In the disclosed embodiment, device 33 will inform device manager 5 1 of the 
number of levels supported by each port 35 on that device 33 when device 33 is activated, reset, or 
turned on. Device 33 may also inform device manager 5 1 at a different time or change the number of 
supported levels dynamically. 

The siring information maintained by device manager 51 for each device includes a string length 

1 5 and a string data type or types supported by device 33. The siring information is used to perform 

conversions between supported string data types of different devices 33. For example, if a device that 
utilizes 8-bit character values to represent strings needs to communicate with a device that uses 16-bit 
character values to represent strings, the string information can be used by device manager 5 1 to convert 
between the different string formats of the devices. 

20 Command information maintained by device manager 51 for each device includes a command 

length and a command data type or types supported by device 33 and may be used to perform 
conversions between command data types as necessary. For example, if a device that supports only 8-bit 
data for commands needs to communicate with a device that supports commands using 16-bit data, the 
command information can be used by device manager 51 to convert between the supported command 

25 types so that the devices may communicate. 

The maintenance information associated with device 33 may include a device type identifier, a 
serial number, a firmware ID, and a version string. If necessary, multiple sets of maintenance 
information may be maintained for a single given device 33. For example, a device 33 with both an 
onboard network communication chip and an onboard CPU may include two sets of maintenance 

30 information, one set for the network chip and one set for the CPU. The device type identifier may 

include a numeric or alphanumeric value representing the type of device. For example, the device type 
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identifier may identify a particular device 33 as a touch pad, a light switch, or an infrared remote control. 
The firmware ID may include an identifier representing the current firmware version and compatible 
updates. 

Device manager 51 on each master controller 28 may also maintain non-local device information 
5 for devices 33 which are not part of the corresponding CAN system of particular master controller 28A- 
D. Non-local devices 33 are devices 33 which are not coupled to same master controller 28 as local 
devices 33. The non-local device information may also include the port information, channel 
information, level information, string information and command information similar to that maintained 
for local devices 33, and additionally includes notification information for non-local devices 33. The 
1 0 notification information includes the status of requests for events from other systems. The notification 
information allows devices 33 to request and receive data and event information from non-local 
devices 33. 

Connection manager 53 operates to manage various physical interfaces, which may include an 
RS232 interface 63, a PhastLink interface 67, as AXLink interface 71, and an Ethernet interface 73. 

15 Connection manager 53 receives information from various interfaces 63, 67, 71 and 73 and dispatches 
the data, with appropriate formatting applied if necessary, to message dispatcher 56. Connection 
manager 53 further provides whatever application-level management various interfaces 63, 67, 71 and 73 
require. Interfaces 63, 67, 7 1 , and 73 may be used to physically and electrically couple devices 33 to 
master controller 28. Interfaces 63, 67, 71 and 73 may also be used to communicate with in tram aster 

20 links 36 to connect one master controller 28 to another master controller 28. Interfaces 63, 67, 71 and 73 
may also be used to couple master controllers 28A-D to the Internet 43. In one embodiment, the Internet 
43 is coupled to master controller 28B through Ethernet interface 73 on master controller 28B. 

Connection manager 53 may also manage communication with a proxy server 76. Proxy server 
76 provides an alternate method for master controller 28B to communicate with the Internet 43. Proxy 

25 server 76 provides master controller 28B with greater security against intrusion and tampering from 
external, unauthorized users connected to the Internet 43 while providing Internet communications 
functionality to master controller 28B. 

Message dispatcher 56 is coupled to connection manager 53 and receives data from connection 
manager 53. Message dispatcher 56 is further coupled to a plurality of modules 77 which include a 

30 diagnostics manager 78, device manager 5 1 , a configuration manager 86, and an IP port manager 88. In 
one embodiment, modules 77 may also include an FTP server 83 and an HTTP server 81 which may not 
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be coupled to message dispatcher 56. 

Message dispatcher 56 operates to route data received from connection manager 53 and other 
modules 77 to appropriate modules 77. Message dispatcher 56 dispatches the data from connection 
manager 53 and other modules 77, such as diagnostics manager 78, configuration 86, and IP port 
5 manager 88, based on the content of the data, the dispatching information from connection manager 53 
and modules 77, and other suitable criteria. 

Diagnostics manager 78 operates to monitor the operational status of devices 33. Diagnostics 
manager 78 may examine specific diagnostic data generated by devices 33 in response to diagnostic 
commands sent to devices 33 and may also examine error messages independently generated by devices 
10 33 and modules 77. 

TCP/IP stack 79 is coupled to the HTTP server 81 and the FTP server 83, and provides TCP/IP 
based protocol and communication services to master controller 28, HTTP server 81 and FTP server 83. 

HTTP server 81 provides Hypertext Transport Protocol (HTTP) services to master controller 28. 
HTTP server 8 1 may be used to receive and respond to commands generated by a user at a remote 
1 5 location, such as a user using web browser 48 (FIGURE 1) to control first or second control area 

networks 16 and 1 8. HTTP server 81 processes the commands through a CGI engine 91 . CGI engine 91 
operates to interpret CGI scripts which define behavior and handling instructions for commands received 
over the Internet 43 by HTTP server 81 . CGI engine 91 provides services which may include security 
and remote control services appropriate to the control area network (such as 1 6 and 1 8), master 
20 controllers 28A-D and devices 33. CGI engine 91 is further coupled to device manager 5 1 and 
manipulates devices 33 through device manager 51. 

FTP server 83 provides file transfer protocol (FTP) services to master controller 28. In 
particular, FTP server 83 may be used to provide FTP- based communications to remote users who 
communicate with master controller 28 over the Internet 43. FTP server 83 may be used to provide, for 
25 example, remote updating of the software and firmware controlling master controller 28. A 

configuration manager 86 operates to configure and reconfigure master controller 28 in suitable ways. 
IP port manager 88 provides suitable management capabilities for the various Internet protocol (IP) 
functionalities on master controller 28. 

Device manager 5 1 is further coupled to an interpreter 93 and a loadable object manager 96. 
30 Interpreter includes a version identifier 94. The version identifier 94 may include an identifier 

representing the current interpreter version and compatible upgrades. Interpreter 93 provides run-time 
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interpretation of the software used to run master controllers 28 and to control devices 33. Interpreter 93 
communicates with loadable object manager 96 to dynamically add new functionality to master 
controllers 28, modules 77 and interpreter 93. 

Given the rapid rate of change and development in the computer and software industries, new 

5 updates, patches, and upgrades often become available during the lifetime of a product. These updates, 
patches and upgrades provide new and enhanced functionality, as well as fixing errors in previous 
versions of the software and hardware associated with the product Master controller 28 may be updated 
in the following manner. In one embodiment, loadable object manager 96 may be used in conjunction 
with FTP server 83 to retrieve software and firmware updates, patches and upgrades from one of the 

1 0 content providers 46 over the Internet 43 and then dynamically add the new functionality provided by the 
patches, updates and upgrades to device manager 51, interpreter 93 and other software and firmware 
associated with master controller 28. The new functionality may be added using loadable object 
manager 96. First, communication is established by a user with one or more of the content providers 46 
via FTP server 83. The user may be using web browser 48 or devices 33 to communicate with content 

1 5 providers 46. A list of available files is then presented to the user. The user selects one or more of the 
available files to be used to update master controller 28. Alternatively, appropriate files may be selected 
automatically for the user by master controller 28 as a function of firmware identifier 97 and version 
identifier 94. Other criteria may be used by the user and master controller 28 in selecting files, such as 
other version and identification information that may be associated with other elements of master 

20 controller 28. For example, device manager 51 and connection manager 53 may include version 

identifiers which could be used in selecting the appropriate files. The selected files may be used to 
update both software and firmware, either individually or in combination, on master controller 28. For 
example, firmware 57 could be updated, as well as software such as device manager 51, interpreter 93, 
and connection manager 53. Other elements of master controller 28 could also be updated. 

25 Firmware 57 provides required suitable functionality at a hardware level to master controller 28. 

In the disclosed embodiment, firmware 57 controls the operations and interactions of interfaces 63, 67, 
71 and 73. The firmware 57 may also control the operation of various other hardware which forms 
portions of master controller 28. Firmware 57 includes a firmware identifier 97. Firmware identifier 97 
may provide identification and version information relating to firmware 57. Firmware identifier 97 may 

30 also serve to identify compatible upgrades, updates and patches that may be applied to firmware 57. 
Firmware identifier 97, in one embodiment, is an alphanumeric value, but may include any suitable 
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representation. 

Device manager 51 is further operable to provide a plurality of virtual elements corresponding to 
physical elements associated with master controllers 28, such as devices 33, ports 35, levels, channels, 
strings, commands, and notifications. Virtual elements may include a plurality of input elements 
5 coupled to output elements of each linked physical element, and a plurality of output elements coupled to 
input elements of each linked physical element FIGURE 3 is a detailed block diagram of a particular 
virtual element, a virtual device 58. Virtual device 58 is a logical construct in device manager 51 which 
may be used to unify or group the behavior of a plurality of physical elements. For example, the virtual 
device 58 may be created by issuing the command DEFIN£_COMBINE(VirtualDevice, PhysicalDevice, 

1 0 PhysicalDevice) to the device manager 5 1 . Virtual device 58 includes a plurality of input elements 

coupled to output elements of each linked physical element, and a plurality of output elements coupled to 
input elements of each linked physical element. 

Virtual device 58 may include a virtual port 61 . Virtual port 61 operates to link a plurality of 
ports 62A, 62B, 62C, 62D, 62E, and 62F having associated levels, channels, strings and commands on a 

15 group of devices 64 A, 64B and 64C with virtual levels, virtual channels, virtual strings and virtual 

commands associated with virtual port 61. The virtual device 58, using the virtual port 61 , maintains a 
logical device representation 65 A, 65B and 65C (shown by dashed lines in FIGURE 3) of respective 
physical devices 64A-C and a logical port representation 66A,66B and 66C of respective physical ports 
62A, 62D, and 62F. For example, virtual port 61 is represented by device manager 51 as the first port 

20 (port 1 ) of device number 4 which is known to device manager 5 1 as one of virtual devices 58. Virtual 
port 61 links port 1 (62A) of device 1, port 2 (62D) of device 2, and port 2 (62F) of device 3. Commands 
v&£ "."vr or information sent to device 4, port 1 (61) are replicated by device manager 51 and individually sent to 
the linked devices, specifically device 1, port 1 (62A), device 2, port 2 (62D), and device 3, port 2 (62F). 
Similarly, the nature of the links between virtual device 4 and the physical elements allows a change in 

25 the level of port 2 (62D) of device 2 to be detected by device manager 5 1 and handled as a change in the 
virtual level of virtual device 4, port 1 (61). The detected change in the level at device 2, port 2 (62D) is 
replicated at the respective levels of device 1, port 1 (62A), and device 3, port 2 (62F) by device manager 
51 and is reported out to master controller 28 as a change in virtual device 4 (58). 

Also, the nature of the links between virtual device 4 and the physical elements confines a 

30 change in the channels, commands and strings of port 2 (62D) of device 2 to be detected by device 
manager 51 and handled as a change in the respective virtual channels, virtual commands and virtual 
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strings of virtual device 4, port 1 (61). In contrast to changes in the levels, the detected change in the 
channels, strings and commands of device 2, port 2 (62D) is not replicated at the respective channels, 
strings and commands of device 1, port 1 (62A), and device 3, port 2 (62F) by device manager 5 1 . 
Stated another way, the output elements of the virtual device 58 (from the virtual device 58 to the 

5 physical devices 33) are maintained in a substantially similar or identical condition, while the input 
elements (from the physical device 33 to the virtual device 58) are not required to be in a substantially 
similar or identical state. 

Each physical element and virtual element may have a state (not shown) associated therewith, 
where the state represents various data values associated with the corresponding element A portion of 

10 the state represents the levels associated with the corresponding element, and a further portion of the 

state represents the channels, strings and commands associated with the corresponding element. Virtual 
elements provide a logical link between the state of the virtual element and the corresponding physical 
element. The behavior of the physical elements may be maintained and updated so that the portion of the 
states representing the respective physical and virtual elements' levels are identical or substantially 

1 5 similar to each other. The portion of the state associated with the virtual element level may also be 

maintained and updated similarly to the portion of the state associated with the physical elements' levels, 
such that the portion of the virtual element's state associated with the virtual element's levels is identical 
or substantially similar to the portion of the state of the respective physical element associated with the 
physical element's levels. The linking between the virtual element levels and the physical element levels 

20 is achieved by replicating commands and propagating state changes found at the virtual element levels to 
the physical element levels, and further by replicating commands and propagating state changes from 
any one of the linked physical elements to the corresponding virtual element and then to the other linked 
physical elements. 

In contrast, the behavior of the channels, strings and commands of the physical elements are 
25 maintained and updated such that changes in the further portion of the state of the virtual element are 
propagated to the further portion of the states of the respective physical elements, while changes in the 
further portions of the states in the physical elements are propagated only to the virtual element. In other 
words, changes in the channels, strings and commands of the virtual element are propagated to all of the 
linked physical elements, but changes in the linked physical elements are only propagated to the virtual 
30 element. 

For example, a change in the state associated with virtual port 61 will be replicated and 
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propagated through logical port representation 66A-66C to physical ports 62A, 62D, and 62F. Similarly, 
a change in the state associated with the level of physical port 62A will be propagated to virtual port 61 
and then replicated by virtual port 6) and propagated to physical ports 62 A and 62F through logical pott 
representations 66A and 66C, respectively. In contrast, a change in the state associated with the 

5 channels, strings and commands of physical port 62A will be propagated only to virtual port 61. 

The virtual elements are treated similarly to their respective physical elements by master 
controller 28. The linking between virtual elements and physical elements, in one embodiment, may be 
performed at compile time and may be changed by rewriting and restarting the program code used to 
control master controller 28. In another embodiment, the linking between virtual elements and physical 

10 elements may be dynamically changed at run time without having to reload the underlying program code 
for master controller 28, for example, by changing the value of a variable in the underlying program code 
and by issuing the command UNCOMBINE_CHANNEI^{VirtualDevice) to the device manager 51. 
Virtual elements are treated in the same manner by master controller 28 as the physical elements and the 
virtual nature of virtual elements is known only to device manager 51 . 

1 5 FIGURE 4 is a flow chart showing a method for routing data between master controllers 28. The 

method begins at step 98 with the activation of master controller 28. As part of device activation step 98, 
master controller 28 may perform whatever initialization and startup preparation suitable for master 
controller 28. 

For convenience, the master controller just activated in step 98 will be referred to as the 
20 "activated master controller" for example, master controller 28A. One or more master controllers 28 

directly connected to the activated master controller will be referred to as "connected master controllers", 
for example, master controller 28B, and all further master controllers 28 which may communicate with 
the activated master controller will be referred to as "other master controllers'*, for example, master 
controllers 28C and 28D. 

25 Next, the method proceeds to step 101 where the activated master controller transmits a 

connections table request to all interfaces on the activated master controller. The connections table 
request is a request by the activated master controller for all information that the connected master 
controllers have regarding the other master controllers and for information regarding the connected 
master controllers themselves. Specifically, the activated master controller is requesting information 

30 regarding one or more paths that may exist between the activated master controller, and the connected 
and other master controllers. Each path is a sequence of master controllers that must be traversed to get 
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from one master controller to another, for example, the activated master controller would have paths 
from the activated master controller to connected and other master controllers. The activated master 
controller will use this information to route data from devices 33 coupled to the activated master 
controller to destinations. These paths are represented by a connections table. The connections table, in 
5 order to represent each path, stores the master controller or master controllers through which data must 
pass to reach a particular master controller. For example, referring to FIGURE 1 , master controller 28A 
is coupled to master controller 28B, and master controller 28B is coupled to master controller 28C, thus, 
master controller 28A will store in the connections table a path from 28A to 28B and a path from 28A to 
28C through 28B. 

10 Proceeding to step 103, the activated master controller 28A receives one or more connections 

tables from one or more of the connected 28B and other master controllers 28C-D. Then, at step 106, the 
activated master controller 28A updates an interna) connections table using the one or more connections 
tables received from the connected 28B and other master controllers 28C-D. 

An example of steps 98-106 is presented in order to further clarify those steps. Referring to 

1 5 FIGURE 1 , when master controller 28A activates (step 98), it transmits a connections table request (step 
101) to master controller 28B. Master controller 28B then sends connections tables representing the path 
from master controller 28A to master controller 28B, and the path from master controller 28A to master 
controller 28C through master controller 28B. Master controller 28B would also include in the 
connections table the path from master controller 28A to master controller 28D through master controller 

20 28B and the Internet 43. After master controller 28A has received the connections tables from master 
controller 28B (step 103), master controller 28A updates its internal connections table so that if one of 
devices 33 coupled to master controller 28A needs to communicate with one of devices 33 coupled to 
master controller 28B-D, master controller 28A will know if the destination device is reachable from 
master controller 28A and if the destination device is reachable, which path the data should be routed 

25 over. The internal connections table may also include a fallback device. The fallback device is a master 
controller that master controller 28A will send data to if the destination device is unreachable. Thus, the 
fallback device comes into use when the master controller does not know how to contact the destination 
device. The goal of the fallback device is that the fallback device will know how to contact the 
destination device even if the master controller using the fallback device did not. 

30 The method continues at step 1 08 where one of devices 33 coupled to activated master controller 

(28A) generates data that is bound for another device 33 (the destination device). Next, at step 111, 
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activated master controller (28A) receives the data. Proceeding to step 1 13, the activated master 
controller (28A) inspects tbe data received from device 33. Inspection step 1 13 is used to determine 
which device is the destination device. In particular, the particular system will be determined and the 
particular device within the system. For example, by consulting system number 27 and an identifier 
5 associated with the device 33. 

Next, at step 1 16, the location of the destination slave device is determined. The destination 
slave device will be in one of three locations: 1 ) the destination device will be coupled to activated 
master controller (28A); 2) the destination slave device will be coupled to one of the connected master 
controllers (28B); or 3) the destination slave device will be coupled to one of the other master controllers 
10 (28C-D). 

Then, at decisional step 1 1 8, if the destination device is coupled to activated master controller 
(28A), then the YES branch of decisional step 1 18 is followed. The YES branch of decisional step 1 18 
leads to step 121 which transfers the data to the destination device and tbe method ends. If the 
destination device is not coupled to activated master controller (28A), then the NO branch of decisional 

1 5 step 1 1 8 is followed to decisional step 123. 

At decisional step 123, if the destination device is coupled to one of the connected master 
controllers (28B), then the YES branch of decisional step 123 is followed and the method proceeds to 
step 126. At step 126, the activated master controller transfers the data to the connected master 
controller (28B) having the destination device coupled thereto. Then the method would proceed from 

20 step 126 to step 128 where the connected master controller (28B) having the destination device coupled 
thereto would transfer the data to the destination device and the method would end. If the destination 
device is not coupled to one of the connected master controllers (28B) then the NO branch of decisional 
step 123 is followed to decisional step 131. 

Proceeding to decisional step 13 1, if the destination device is coupled to one of the other master 

25 controllers (28C-DX then the YES branch of decisional step 1 3 1 is followed and the method proceeds to 
step 1 33. If the destination slave device is not coupled to one of the other master controllers (28C-D), 
then the NO branch of decisional step 13 1 is followed to step 136. 

If the YES branch of decisional step 13 1 is followed, the method proceeds to step 133. In step 
133, the data is transferred from master controller to master controller until the master controller having 

30 the destination device coupled thereto is reached. The data is first transferred from the activated master 
controller (28A) to the connected master controller (28B) which is the first master controller on the path 
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to the master controller having the destination device coupled thereto. The connected master controller 
which receives the data then passes the data on to the next master controller on the path to the master 
controller having the destination device coupled thereto. The data continues to be passed on to further 
master controllers until the master controller having the destination device coupled thereto is reached. 

5 If the NO branch of decisional step 1 3 1 is followed, the method proceeds to step 1 36 where the 

data is transferred to the fallback device. As described above, the fallback device represents a master 
controller that the activated master controller will transfer information to if the destination device is 
coupled to a master controller not known to the activated master controller (28A). Stated another way, if 
the activated master controller (28A) has no path in its internal connections table to the master controller 

1 0 having the destination device coupled thereto, the activated master controller (28A) will transmit the data 
to the fallback master controller in the hope that the fallback master controller will know of a path to the 
master controller having the destination device coupled thereto. 

Proceeding to decisional step 138, after the data has been transferred to the fallback device in 
step 136 the fallback master controller determines if it knows of the master controller having the 

1 5 destination slave device coupled thereto. If the fallback master device knows of the master controller 
having the destination slave device coupled thereto, the YES branch of decisional step 138 is followed 
and the method proceeds to step 1 33 to transfer the data as described above. If the fallback master does 
not know of the master controller having a destination slave device coupled thereto, the NO branch of 
decisional step 138 is followed and the fallback master will transfer the data to its fallback master 

20 controller in the hope that its fallback master controller will know of the master controller having the 
destination slave device coupled thereto. Once the fallback master controller receives the data, the 
fallback master will operate in a manner similar to the activated master controller (28A) to attempt to 
find the master controller having the destination device coupled thereto. 

The data further includes a transfer count that tracks the number of master controllers the data 

25 has been transferred to. If the transfer count exceeds a predetermined point then the destination device is 
considered to be completely unreachable, the data is discarded and an error message is generated. 

FIGURE 5 is a flowchart showing a method for operating virtual elements by a master controller 
28 in a control area network (16 and 18) according to an embodiment of the teachings of the present 
invention. The method begins at step 151 where the virtual element is defined. As noted previously in 

30 association with FIGURE 3, the virtual element is a logical construct used to group physical elements 

such as devices 33, ports 35, levels, channels, strings, commands, and notifications. The virtual element 
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is defined by linking at least two physical elements with one virtual element. Multiple virtual elements 
may share particular physical elements and multiple physical elements may share particular virtual 
elements. In one embodiment, the virtual element is virtual device 58 and the physical elements are 
devices 33 (referred to as "physical devices 33" in the context of FIGURE 5 in order to clearly 

5 differentiate virtual and physical devices). 

Next, the method proceeds to step 153 where a virtual device state associated with the virtual 
device 58 is linked with physical device states respectively associated with physical devices 33, which 
are linked to virtual device 58. Generally, virtual elements will have an associated state and physical 
elements will also have an associated state. The virtual device state represents data values associated 

10 with the virtual device, and the physical device state represents a plurality of data values associated with 
the physical device. The virtual device state and the respective physical device states are linked such 
that the virtual and physical device states may be maintained in a substantially similar condition. The 
linked virtual and physical device states may also be maintained in an identical condition. 

The method proceeds to decisional step 1 56 where a check is made for a request to change the 

1 5 virtual device state. The virtual device state may change in response to a data state change request 
received at the virtual device 58 or to other suitable criteria. If no request to change the virtual device 
state is detected, then the NO branch of decisional step 156 is followed to decisional step 168. If a 
request to change the virtual device state is detected, then the YES branch of decisional step 1 56 is 
followed to step 158. 

20 From the YES branch of decisional step 1 56 the method proceeds to step 1 58, where the method 

updates the virtual device state in response to the request to the change the virtual device state. Then, at 
step 161 , the method replicates the change in the virtual device state. In one embodiment of the present 
invention, the change in the virtual device state is replicated by generating a data state change request 
for each respective physical device 33 linked to the virtual device 58. Each generated data state change 

25 request is tailored to induce a change in the corresponding physical device state which is substantially 
similar to the change induced in the virtual device state. The induced change in the physical device may 
also be identical to the change in the virtual device. 

Next, at step 163, the method sends the generated data state change requests to respective 
devices and, at step 166, the respective physical device states are updated in response to the 

30 corresponding generated data state change requests. 

Returning to the NO branch of decisional step 156, the method proceeds to decisional step 168 
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where a check is performed for a request to change one or more of the respective physical device states. 
If no request to change one more of the physical device states is detected, then the NO branch of 
decisional step 1 68 is followed to step 1 83. If a request to change one or more of the physical device 
states is detected, then the YES branch of decisional step 168 is followed to step 171 where the method 
5 updates the respective physical device states. Then, at step 173, the change in the respective physical 
device state is replicated and, at step 176, sent to the virtual device 58. In one embodiment of the present 
invention, a data state change request is received at one or more of the respective physical devices 33 and 
a copy of the received data state change request is sent to the virtual device 58. Proceeding to step 1 78, 
the method updates the virtual device state in response to the copy of the data state change request from 
10 step 173. 

Next, at decisional step 181, the method determines if the data state change request effected a 
change in the state of the levels respectively associated with the physical devices 33. If a state change is 
not detected in the levels, but rather in the channels, strings and commands, then the NO branch of 
decisional step 181 is followed and the method proceeds back to step 156. 

15« If a state change is detected in die levels then the method replicates the state change induced in 

the virtual device state by copy of the data state change request from step 1 73 by generating at least one 
data state change request for each physical device 33 linked to the virtual device 58 except for the 
physical device 33 that has already updated its corresponding physical device state in step 171. Stated 
another way, virtual elements link or unify the behavior of physical elements such that a change in the 

20 virtual element state is reflected in the respective physical element states associated with linked physical 
elements, and a change in one or more physical element states is reflected in the virtual element state and 
the other respective physical element states. Thus, in step 1 8 1, the method is reacting to a change in one 
or more physical device states that must be propagated or replicated at the virtual device 58 and also at 
the other linked physical devices 33. Therefore, no generated state change request need be generated for 

25 the physical device 33 that is inducing the state change in the virtual device state and the other linked 
physical device states since the excluded device's state was already updated at step 171. The method 
then follows the YES branch of decisional step 181 back to step 163 where the generated state change 
requests generated in step 181 are sent to corresponding physical devices 33. 

Returning to the NO branch of decisional step 168, the method proceeds to step 1 83 where the 

30 method performs any modifications to the virtual elements indicated by input from the user, master 

controller 28 or other suitable input, to change one or more virtual elements. Modifications to the virtual 
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elements may include linking additional physical elements to a particular virtual element or elements, 
removing physical elements from a particular virtual element or elements, creating a entirely new virtual 
element, and deleting an entire virtual element In one embodiment, modification step 183 is performed 
using virtual device 58 and physical devices 33. The method then returns to step 156 and continues to 
5 maintain linked virtual and physical element states until the method is commanded to end (not shown). 

FIGURE 6 is a flowchart showing a method for dynamically updating master controllers 28 in a 
control area network (16 and 1 8) according to an embodiment of the teachings of the present invention. 
The method begins at step 201 where master controller 28 connects to a remote site. In one embodiment 
of the present invention, the remote site is one or more of content providers 46 and the connection to 
10 content providers 46 is created over the Internet 43 using FTP server 83 (shown in FIGURE 1). The 
connection with the remote site may be initiated automatically by master controller 28, in response to 
user input or in response to any suitable criteria. For example, based on version identifiers associated 
with software or firmware, the master controller 28 could actively search out updates, upgrades and 
patches. 

1 5 Next, at step 203, the method receives or retrieves a list of files available from the remote site. 

Then, at step 206, the method selects at least one of the files in the list. The selection may be performed 
manually by the user, automatically by master controller 28 and by a combination of manual input and 
automatic selection. In particular, the selection may be based on one or more version identifiers and 
firmware identifier 97 (shown in FIGURE 2), but any other suitable criteria may be used. 

20 Version identifiers be used to identify version, age, compatibility and other information 

associated with software on master controller 28. Software may include content provider interfaces to 
;I. . provide communication services with various content providers, other user or retailer added software, or 
other suitable software. For example, a security and home protection service may load custom software 
onto master controller 28. The software elements may have respective associated identifiers that may be 

25 used by the present method or the various software elements may share identifiers. 

Firmware identifier 97 may be used to determine the version, age, compatibility and other 
criteria associated with firmware 57 on master controller 28. The firmware 57 may also include 
firmware associated with the interfaces 63, 67, 71 and 73, interpreter 93, any modules 77, message 
dispatcher 56, CGI engine 91, proxy server 76 and connection manager 53, as well as any other suitable 

30 part of master controller 28 which is implemented in firmware. In addition, the various pieces of 

firmware may have individual identifiers associated with them as well as being able to share firmware 
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identifier 97. 

Version identifiers and firmware identifier 97 may be used alone or in combination with each 
other to determine which files in the list are compatible with the software and firmware 57 on master 
controller 28, as well as whether the files in the list are older or newer than the software and firmware 57 
on master controller 28. 

Then, at step 208, the files selected in step 206 are retrieved from the remote site. Proceeding to 
step 21 1, the software and the firmware may be updated either individually or collectively. 

The software may be updated while the software is in use. Stated another way, master controller 
28 does not need to be reset or interrupted in any substantial way in order to update the software using 
the files selected for updating the software. The firmware may also be updated without resetting or 
interrupting master controller 28. In one embodiment, the loadable object manager 96 (shown in 
FIGURE 2) is used to update the software and firmware 57 on master controller 28. 

Based on the selected files, master controller 28 or the user may determine that only one of the 
software and firmware 57 need to be updated. If the method determines that only the software needs to 
be updated then only the software will be updated, similarly, if the method determines that only the 
firmware needs to be updated then only the firmware will be updated. The software and firmware 57 
may also be updated collectively, for example, by simultaneously updating both. 

Once the software and/or firmware have been updated, the method ends until invoked again 
either automatically by master controller 28, in response to user input or in response to other suitable 
criteria. 

The present invention provides a number of technical advantages. One such technical advantage 
is the ability to unify the states of a virtual element and a plurality of physical elements associated with 
the virtual element. Another such technical advantage is the ability to dynamically create and modify a 
linking between a state associated with the virtual element and a respective state associated with the 
plurality of physical elements linked with the virtual element. 

It should be recognized that direct connections disclosed herein could be altered, such that two 
disclosed components or elements would be coupled to one another through an intermediate device or 
devices without being directly connected, while still realizing the present invention. Other changes, 
substitutions and alterations are also possible without departing from the spirit and scope of the present 
invention, as defined by the following claims. 
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WHAT IS CLAIMED IS: 

1 . A control area network comprising: 
a master controller, 

a first device and a second device coupled to said master controller, said first device having a 
5 first state representing a plurality of data values associated with said first device and said second device 
having a second state representing a plurality of data values associated with said second device; and 

a virtual device associated with said first and second devices, said virtual device having a virtual 
device state representing a plurality of data values associated with said virtual device, said virtual device 
linking said virtual device state to said first and second states. 

10 

2. The control area network according to claim 1 , wherein said first and second devices are 
each a port and said virtual device is a virtual port 

3. The control area network according to claim 1 , wherein said first and second devices are 
1 5 each levels and said virtual device is a virtual level. 

4. The control area network according to claim 1 , wherein said first and second devices are 
each channels and said virtual device is a virtual channel. 

20 5. The control area network according to claim 1 further including a device manager 

associated with said master controller. 

6. The control area network according to claim 5 wherein said device manager is operable 
to utilize said virtual device to maintain said virtual device state and said first and second states in a 

25 substantially similar condition. 

7. The control area network according to claim 5 further including a data state change 
request being received by said virtual device, a first generated data state change request being generated 
by said device manager based on said data state change request and sent to said first device, and a second 

30 generated data state change request being generated by said device manager based on said data state 
change request and sent to said second device. 
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8. The control area network according to claim 7, wherein said data state change request is 
a command sent by said master controller in the control area network. 

9. The control area network according to claim 7, wherein said virtual device state is 

5 updated in response to said data state change request, said first state is updated in response to said first 
generated data state change request and said second state is updated in response to said second data state 
change request. 

10. The control area network according to claim 7, wherein said first and second generated 
1 0 data state changes request are generated by replicating said data state change request received by said 

virtual device such that said first and second generated data state change requests are substantially 
similar to said data state change request 

1 1 . The control area network according to claim 1 0, wherein said first and second devices 
1 5 are each operable to respond to input by changing said respective first and second states, wherein the 

change in said first state effects substantially similar changes in said virtual device state, and wherein the 
change in said second state effects substantially similar changes in said virtual device state. 

12. The control area network according to claim 1 1 , wherein said input is an external input 
20 from an associated external device. 

13. The control area network according to claim 1 1, wherein said input is an external input 
from a user. 

25 14. The control area network according to claim 10 further including level input, wherein 

each of said virtual device state and said first and second states include a level data portion therein, 
wherein said first and second devices are each operable to respond to said input by changing said level 
data portion of said respective first and second states, wherein the change in said level data portion of 
said first state is replicated in said level data portion of said virtual device state by said device manager 

30 and the change in said level data portion of said first state is replicated in said level data portion of said 
second device state by said device manager, and wherein the change in said level data portion of said 
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second state is replicated in said Jevel data portion of said virtual device state by said device manager 
and the change in said level data portion of said second state is replicated in said level data portion of 
said first device state by said device manager such that each of said level data portions of said virtual 
device state, said first device state and said second device state are maintained in a substantially similar 
5 condition. 

1 5. The control area network according to claim 1 0 further including channel change input, 
wherein each of said virtual device state and said first and second states include a channel data portion 
therein, wherein said first and second devices are each operable to respond to said channel change input 
10 by changing said channel data portion of said respective first and second states, wherein the change in 

said channel data portion of said first state is replicated in said channel data portion of said virtual device 
state by said device manager, and wherein the change in said channel data portion of said second state is 
replicated in said channel data portion of said virtual device state by said device manager. 

15 16. The control area network according to claim 1 0 further including string change input, 

wherein each of said virtual device state and said first and second states include a string data portion 
therein, wherein said first and second devices are each operable to respond to said string change input by 
changing said string data portion of said respective first and second states, wherein the change in said 
string data portion of said first state is replicated in said string data portion of said virtual device state by 

20 said device manager, and wherein the change in said string data portion of said second state is replicated 
in said string data portion of said virtual device state by said device manager. 

17. The control area network according to claim 1 0 further including command change 
input, wherein each of said virtual device state and said first and second states include a command data 

25 portion therein, wherein said first and second devices are each operable to respond to said command 

change input by changing said command data portion of said respective first and second states, wherein 
the change in said command data portion of said first state is replicated in said command data portion of 
said virtual device state by said device manager, and wherein the change in said command data portion 
of said second state is replicated in said command data portion of said virtual device state by said device 

30 manager. 
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J 8. The control area network according to claim 5, wherein said linking between said virtual 
device and said first and second devices may be created at run-time. 

19. The control area network according to claim 5, wherein said linking between said virtual 
device and said first and second devices may be modified at run-time. 

20. The control area network according to claim 5, wherein said linking between said virtual 
device and said fust and second devices may be defined only at compile time and may only be changed 
by resetting said master controller. 

21. A control area network comprising: 
a master controller, 

a plurality of devices coupled to said master controller, each said device having a respective state 
representing a plurality of data values associated with said respective devices; and 

a virtual device associated with a set of said devices, said virtual device having a virtual device 
state representing a plurality of data values associated with said virtual device, said virtual device linking 
said virtual device state and said respective states associated with said set 

22. The control area network according to claim 21 , wherein said virtual device state and 
said respective states are maintained in a substantially similar condition. 

23. The control area network according to claim 21 further including a device manager 
associated with said master controller and said virtual device being further associated with said device 
manager. 

24. The control area network according to claim 23 further including a data state change 
request received by said virtual device, a plurality of respective device state change requests generated 
by said virtual device for each device in said set in response to said data state change request and 
wherein said device state change requests are sent to said each device in said set. 
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25. The control area network according to claim 24, wherein said data state change request 
is a command sent by said master controller in the control area network. 

26. The control area network according to claim 24, wherein said virtual device updates said 
virtual device state in response to said data state change request and each of said devices in said set 
update said respective states in response to said device state change requests. 

27. The control area network according to claim 24, wherein said device state change 
requests are generated by replicating said data state change request received by said virtual device such 
that each said device state change request is substantially similar to said data state change request. 

28. The control area network according to claim 27 further including level input, wherein 
each of said virtual device state and said respective states include a level data portion therein, wherein 
said devices in said set are each operable to respond to said level input by changing said level data 
portion of said respective states, wherein the change in said level data portion of state of one of said 
devices in said set is effected in said level data portion of said state associated with each of said devices 
in said set distinct from said one of said devices in said set and in said level data portion of said virtual 
device state such that each of said level data portions of said respective states associated with said 
devices in said set and said virtual device state are maintained in a substantially similar condition. 

29. The control area network according to claim 27 further including channel change input, 
wherein each of said virtual device state and said respective states include a channel data portion therein, 
wherein said devices in said set are each operable to respond to said channel input by changing said 
channel data portion of said respective states, wherein the change in said channel data portion of state of 
one of said devices in said set is effected in said channel data portion of said virtual device state. 

30. The control area network according to claim 27 further including string change input, 
wherein each of said virtual device state and said respective states include a string data portion therein, 
wherein said devices in said set are each operable to respond to said string input by changing said string 
data portion of said respective states, wherein the change in said string data portion of state of one of said 
devices in said set is effected in said string data portion of said virtual device state. 
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3 1 . The control area network according to claim 27 further including command change 
input, wherein each of said virtual device state and said respective states include a command data portion 
therein, wherein said devices in said set are each operable to respond to said command input by changing 
said command data portion of said respective states, wherein the change in said command data portion of 

5 state of one of said devices in said set is effected in said commanddata portion of said virtual device 
state. 

32. The control area network according to claim 28, wherein said level input is from an 
associated external device associated with said devices. 

10 

33. The control area network according to claim 28, wherein said level input is an external 
input from a user. 

34. The control area network according to claim 21, wherein said linking between said 
1 5 virtual device state and said respective device states may be created at run-time. 

35. The control area network according to claim 2 1 , wherein said linking between said 
virtual device state and said respective device states may be modified at run-time. 

20 36. The control area network according to claim 21 , wherein said linking between said 

virtual device state and said respective device states may be defined only at compile time and may only 
be changed by resetting said master controller. 

37. A method for supporting a virtual device on a master controller in a control area network 
25 comprising: 

associating the virtual device to a plurality of devices; 

linking a plurality of data states respectively associated with the virtual device and each of the 
plurality of devices associated with the virtual device; and 

maintaining each respective data state in a substantially similar condition. 

30 
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38. The method according to claim 37, wherein maintaining each respective data state in a 
substantially similar condition includes: 

receiving a data state change request at the virtual device, wherein the data state change request 
effects a change in the data state of the virtual device; and 
5 replicating the data state change request for each of the devices associated with the virtual 

device. 

39. The method according to claim 38, wherein replicating the command for each of the 
devices associated with the virtual device further includes changing the data state of the virtual device in 

10 response to the data state change request, and wherein maintaining each respective data state in a 

substantially similar condition further includes changing the data state of each of the devices associated 
with the virtual device in response to the replicated data state change request. 

40. The method according to claim 39, wherein the data state change request is a command 
1 5 sent by the master controller in the control area network. 

4 1 . The method according to claim 37, wherein maintaining each respective data state in a 
substantially similar condition includes: 

receiving a data state change request at a one of the devices associated with the virtual device; 

and 

sending the data state change request to the virtual device. 

42. The method according to claim 41 , wherein receiving a data state change request at a one 
of the devices associated with the virtual device includes changing the data state of the one of the devices 
in response to the data state change request. 

43. The method according to claim 42, wherein the data state change request is a command 
sent by a master controller in the control area network. 

30 44. The method according to claim 37, wherein maintaining each respective data state in a 

substantially similar condition includes: 
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receiving a level state change request at a one of the devices associated with the virtual device; 
sending the level state change request to the virtual device; 

changing a level data state portion of the data state of the virtual device in response to the level 
state change request; 

5 replicating the level state change request for each of the devices associated with the virtual 

device; and 

changing a level data portion of the data state of each of the devices associated with the virtual 
device in response to the replicated data state change request. 

10 45. The method according to claim 44, wherein the data state change request is a command 

sent by a master controller in the control area network. 
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SYSTEM AND METHOD OF DEVICE INTERFACE 
CONFIGURATION FOR A CONTROL SYSTEM 



TECHNICAL FIELD OF THE INVENTION 

This invention is related in general to the field of control system. More particularly, the invention 
is related to system and method of device driver configuration for a control system. 

5 BACKGROUND OF THE INVENTION 

In a fully automated environment, appliances that change the various parameters of the environment 
can be inked to a control area network (CAN) and a computer-based controller. The appliances may include 
heating, ventilation and air conditioning (HVAC) systems, lighting systems, audio-visual systems, 
telecommunications systems, security systems, surveillance systems, and fire protection systems, for 
1 0 example. One or more easy-to-use user interface, such as a touch panel, may be electronically linked to the 
control area network to accept user input and display current system status. AMX Corporation of Dallas, 
Texas designs and manufactures such networked appliance control systems. 

SUMMARY OF THE INVENTION 

1 5 Accordingly, there is a need for a system and method of device interface configuration For a control 

system. 

In accordance with the present invention, a system and method of device interface configuration For 
a control system are provided which eliminate or substantially reduce the disadvantages associated with prior 
control systems. 

20 In one aspect of the invention, a control system comprises a master controller and at least one device 

coupled to the master controller via a network. At least one generic device interface module resides on the 
master controller, where the device interface module defines a basic protocol for interface with any device. 
Configuration information associated with the at least one device is used to tailor the at least one generic 
device interface module to communicate and operate with the at least one device. 

25 In another aspect of the invention, a method of communicating with a device in a control area 

network includes the steps of automatically obtaining configuration information associated with the device, 
where the configuration file includes communication and operating protocol of the device. A specific 
instance of a generic device interface object is then generated using the configuration information associated 
with the device, and 
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communication with the device is then performed with the specific object instance. 

In yet another aspect of the invention, a control area network includes a master controller, and at least 
one device coupled to the master controller via a local area network. At least one generic device interface 
object resides on the master controller, where the at least one device interface object defines a basic protocol 
for interface with any device. A configuration file associated with the at least one device is used to tailor 
the at least one generic device interface object to generate a specific interface object instance operable to 
communicate and operate with the at least one device. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a better understanding of the present invention, reference may be made to the accompanying 
drawings, in which: 

FIGURE 1 is a simplified top-level block diagram of a system and method of coupling one or more 
control systems to the Internet constructed according to an embodiment of the present invention; 

FIGURE 2 is a more detailed block diagram of a system and method of coupling one or more control 
systems to the Internet constructed according to an embodiment of the present invention; 

FIGURE 3 is a more detailed block diagram of a master controller with a system and method of 
device interface configuration constructed according to an embodiment of the present invention; 

FIGURE 4 is a flowchart of a process for bringing a new device on-line according to an embodiment 
of the present invention; 

FIGURE 5A is a block diagram of a process for configuring a device interface object according to 
an embodiment of the present invention; 

FIGURE 5B is a block diagram of an exemplary screen for installing a new device according to an 
embodiment of the present invention; 

FIGURES 6A-6F are exemplary command windows for programming commands according an 
embodiment of the present invention; and 

FIGURES 7A-7C are exemplary conditional variable windows for programming conditional 
variables according to an embodiment of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

FIGURE 1 is a simplified top-level block diagram of a system and method 10 of Internet control 
system which couple one or more control systems to the Internet constructed according to the teachings of 
the present invention. The implications of employing system and method 1 0 of the present invention are the 
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ability to communicate with, control, and be controlled by one or more Internet nodes or Internet applications 
that act as one or more devices in a control system connected by a control area network (CAN). These 
Internet applications may include web browsers, web server applications of information content providers, 
and email applications. In other words, the geographical and communication protocol boundaries are 
5 transparent between a local control area network and the Internet, so that the Internet, web information 
content providers and web browser applications become devices in the control system. By definition, a 
device in the control system can send control commands to and/or receive control messages from a master 
controller on the control area network. Hereinafter, the word Internet may be also used to refer to an Intranet 
or the World Wide Web and vice versa. 

10 System ] 0 includes a control network porta) 12 coupled between the Internet 22 and one or more 

control area networks 30 and 3 1 . Control area networks 30 and 3 1 are local area networks operating under 
transport protocols such as Ethernet, and AXLink and PHASTLink® of AMX Corporation (Dallas, Texas) 
that interconnect a variety of devices, appliances and/or equipment The underlying network connectivity 
34 may be wired, wireless, power line carriers, or any suitable transmission medium. Coupled to control area 

1 5 networks 30 and 3 1 are a plurality of devices, appliances and/or equipment, including control area network 
user interfaces (CAN UI/F) 35, master controllers 36, and Internet appliances 37-39. Some devices may be 
coupled to control area networks 30 and 3 1 via additional intermediate communications devices, such as an 
RS 232 controller (not shown). 

Control area network user interface device 35 is any device that is capable of receiving user input 

20 and displaying or indicating control network status. For example, a touch panel, a computer terminal with 
a monitor, keyboard and pointing device, and any device with similar functionalities may serve as control 
area network user interface 35. As described in detail below, with the use of control area network portal 12 
of the present invention, Internet applications are also capable of functioning as control area network user 
interface devices without the use of custom and dedicated applications on the user's end. 

25 Master controller 36 is generally a CPU-based controller that controls the communications among user 
interface 35 and Internet appliances 37-39. It is operable to receive user inputs received by user interface 
devices, such as commands, and instruct the appropriate Internet appliance to act according to the command. 
Master controller 36 may also poll each device in control area network 30 periodically to monitor its status. 
The system status and/or the status of each device may be sent to control area network user interface devices 

30 for display. 

Internet appliances 37-39 are devices that can receive commands from master controller 36 and operate or 
act according to the command. Internet appliances 37-39 may include equipment that affect or monitor the 
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various parameters of the premises. For example, Internet appliances 37-39 may include heating and air 
conditioning, lighting, video equipment, audio equipment, sprinklers, security cameras, infrared sensors, 
smoke detectors, etc. in a residential or commercial control area network. Household appliances, such as 
a hot tub, fireplace, microwave oven, coffee maker, etc. may also be Internet appliances coupled to the 
5 network. Internet appliances 3 7-3 9 may also be capable of providing a current status of its operational state 
to master controller 36, such as on/off, temperature settings, current ambient temperature, light intensity 
settings, volume settings, threshold settings, and predetermined alphanumeric strings reflective of operational 
states. 

Master controller 36 is also operable to receive user input from nodes of the Internet 22 via control 

10 network portal 12. Connected to Internet 22 are content providers 25 and 26, which may also function as 
control area network user interface devices. Content providers 25 and 26 are typically web servers that 
generate and provide static and/or dynamic information and content in the form of web pages. Content 
provider applications executing on the web server are able to mine data stored in databases (not shown). The 
web pages are typically developed with hypertext markup language (HTML), and various other scripting 

] 5 languages and programming environments such as Microsoft Active Server Pages (ASP), Common Gateway 
Interface (CGI), Internet Server Application Programming Interface (ISAPJ), JAVA, ActiveX, Cold Fusion, 
etc that make the web pages more dynamic and interactive. 

Also connected to the Internet 22 are web browsers 23 and 24 that may also serve as control area 
network user interfaces. Web browsers 23 and 24 are application programs that can be used to request web 

20 pages from content providers 25 and 25 and decode the web pages. Web browser applications include 
NETSCAPE NAVIGATOR and MICROSOFT INTERNET EXPLORER, for example. Typically, a user 
executes a web browser application on her personal computer and accesses the World Wide Web via a 
dial-up connection to an Internet service provider. The Internet or World Wide Web may also be accessed 
via other means such as cable modems and digital subscriber lines (DSL). The user makes a request for a 

25 particular web page or particular web site by entering or specifying a uniform resource locator (URL). The 
URL is associated with an Internet protocol (IF) address of the specified web site. Every computer connected 
to the World Wide Web and Internet has a unique IP address. This address is used to route message packets 
to specific computers and users. Internet protocol or IP is the message transport and communications 
protocol of the Internet and World Wide Web. 

30 When the web browser requests a certain URL, a connection is first established with a web server 

of a content provider that is addressed by the URL. A hypertext transport protocol (HTTP) request is then 
issued to the web server to download an HTML file. The web server receives the request and sends a web 
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page file to the web browser, which decodes the file to display information in speci fled format on the screen. 
Web pages with dynamic content provided by gateway interfaces such as CGI and ISAPI are executable 
applications that are ran by the web server upon user request. The executing gateway application is able to 
read parameter information associated with the request and generate an output in the form of an HTML file 
5 in response to the parameter values. Another way to add dynamic and interactive content to web pages uses 
ASP. ASP scripts are server-side executable scripts that are directly incorporated in the HTML web pages. 
Upon request for the page, the web server executes the ASP script in response to input parameter values and 
generates the web page with dynamic content. 

Using control network portal 1 2, users may access control area networks 30 and 3 1 via web browsers 

10 23 and 24 accessing web pages provided by control network portal 12 or value-added web pages provided 
by content providers 25 and 26. For example, a user who has a control area network deployed in her luxury 
residence to control various aspects of the home environment may use a web browser application to remotely 
monitor her home. She may change the temperature setting to decrease energy use, for example, because she 
will be leaving on a business trip straight from work. She may also use the surveillance cameras to visually 

1 5 ensure security has not been breached. She may even be able to remotely program her VCR to record certain 
favorite programs that will be broadcast while she is away. 

An example of value-added web pages provided by content providers is the provision of an interactive 
version of the television programming web page, www.tvguide.com. A user may request this web page, 
determine available program choices, and click on a certain program. Options may be provided to enable 

20 the user to turn on the television and tune to a particular channel scheduled to broadcast the selected program 
or to program the VCR to record the selected program. 

Another example of value-added web pages provided by content providers is the provision of a 
secured web page that an electric company may access to slightly raise the temperature settings of the air 
conditioning systems of its participating customers in anticipation of high demand brown out conditions. 

25 Yet another example is a web page that a security company may use to access, monitor and control the 
security, surveillance and fire protection systems of its customers. 

FIGURE 2 is a more detailed block diagram of a system and method 10 of coupling one or more 
control system to the Internet constructed according to an embodiment of the present invention. Control area 
network portal 12 may include a web server 13 coupled to the Internet 22. Web server 13 is also coupled 

30 to an Internet appliance (I A) server 14, which may also be coupled to a control network server 40. Control 
network server 40 is coupled to control area network 30 that links several appliances and systems, such as 
fire protection systems 50, heating, ventilation and air conditioning (HVAC) systems 5 1 , lighting systems 
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52, audio and visual systems 53, and security systems 54. Control area network 30 is also coupled to user 
interface devices 55 and master controller 36. 

It may be noted that control network portal 1 2 may be implemented by a single stand-alone system 
that has sufficient memory and processing power or several separate systems with distinct functions as shown 
5 in FIGURE 2. Web server 13 is operable to receive requests of web pages from web browser 23 and to 
respond by generating and providing the requested web pages. The information content of the web pages 
may be dynamically obtained by communicating with IA server 1 4, which is operable to communicate with 
master controller 36 via control network server 40 to obtain status and other information. Control network 
server 40 is used only if there is protocol conversion or other control issues needed to operate the control area 
1 0 network. It may be thought of, logically, that IA server 1 4 is directly coupled to the network and functions 
as a device on the network. Commands entered at a web browser are sent to web server 1 3, which relays the 
commands to master controller 36 via 1 A server 1 4 and control network server 40. Master controller 36 then 
instructs appropriate appliances and/or systems in the control network to act according to the received 
command. 

1 5 FIGURE 3 is a more detailed block diagram of a master controller 36 with a system and method of 

device interface configuration constructed according to an embodiment of the present invention. Master 
controller 36 includes an installation software 100 which may be used to install and configure the 
components in a control system. Installation software 100 defines a generic device interface object 102, 
which may be configured by device interface object configuration files 104 to instantiate objects 106-1 10 

20 tailored to specific devices made by specific manufacturers, such as a television set 1 12, a VCR 1 1 4, and a 
CD changer 1 16, for example for a home entertainment application. Each device may also include its own 
embedded configuration file for upload to master controller 36 when the device is brought on-line. Each 
configuration file 104 includes device-specific protocol information related to a specific device. Instances 
1 06-1 1 0 enable master controller 36 to tailor its installation software 1 00 for the installation of the specific 

25 devices and further allows master controller 36 to communicate with the specific devices. 

This configuration technique is shown in more detail in FIGURE 5A. Instances of generic device 
interface object 102 are generated by reading or loading configuration files which describe specific devices 
made by specific manufacturers. For example, loading a configuration file 160 of device number 1 1 1 made 
by company ABC causes an instance 162 of generic device interface object 102 that has knowledge of the 

30 specifics of that device to be generated. Similarly, the same generic device interface object 102, when 
characterized by a configuration file 164 for device number 124 made by company ABC, generates an ABC 
device 124 interface object instance 166. Configuration file 168 describing the characteristics of device 
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number 260 manufactured by company XYZ causes an XYZ device 260 interface object to be instantiated 
from generic device interface object 102. Further, configuration file 172 describing the characteristics of 
device number 143 manufactured by company MN causes an MN device 143 interface object to be 
instantiated from generic device interface object 102. With the system and method of the present invention, 
5 device drivers for new devices may be generated in substantially shortened development time. 

FIGURE 4 is a flowchart of a process 120 for bringing a new device on-line according to an 
embodiment of the present invention. When a new device is first "plugged" into the control area network, 
it communicates with master controller 36 to announce its presence. The information the new device 
conveys to master controller 36 may include a manufacturer name and device type. With this information, 

10 master controller 36 may display an unattached hardware icon representing the new device. Master 
controller 36 queries the new device to get its configuration file information, as shown in block 122. Master 
controller 36 then examines its loaded configuration files in block 124 to determine if a configuration file 
for the new device exists, as shown in block 126. If a configuration file for the new device does not exist, 
then a configuration file is obtained from the new device over the control network link, as shown in block 

15 128. The configuration file is then saved into a directory, as shown in block 130. If the configuration for 
the new device does exist, then the configuration file is compared with the configuration file information 
obtained from the new device. The configuration file information may include a file name and a version 
number. If the pre-existing configuration file in master controller 36 does not have the same or a later 
version than the configuration file in the new device, then the newer version configuration file is obtained 

20 from the new device and saved, as shown in blocks 128 and 130. Operating in this manner, the newest 
available version of the configuration file is automatically loaded into master controller 36. 

In block 134, the configuration file is displayed or otherwise indicated as an unattached software 
object icon on a tool bar or somewhere on the screen. Recall that the unattached new device icon is also 
displayed on the screen. At this point in the installation process, the user may provide some form of input 

25 to associate the unattached software object with the unattached new device, as shown in block 140. For 
example, this may be accomplished by dragging the unattached software object icon onto the unattached new 
device icon or vice versa, as shown in block 136. FIGURE 5B is an exemplary screen shot 190 illustrating 
this concept, where object interface icons 162-174 are associated with device icons 192-198, respectively. 
Once this step is performed, a specific device interface object can be instantiated, as shown in block 138. 

30 Alternatively, the interface object instances may be generated when the configuration file is loaded in block 
128 or upon startup when all configuration files 104 are loaded into installation software 100 prior to 
bringing the new device on-line. The process ends in block 142. 
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It may be seen that device object configuration files are what gives generic device interface object 
the specific details about certain devices. An example of a device object configuration file and brief 
description are provided below: 

5 [Device Information] 

Manufacturer=P3 Partner 

Device Name=Test File Version L0 

ToolBar Location=Misc 

Hardware Name=A/V Device 
10 MfgNum=18 

Device Num=17 

Toolbar Icon=TooIbarlcon.bmp 

Icon Active^Activelcon.bmp 

Icon lnactive=]nactiveIcon.bmp 
1 5 Toolbar U)caiion= Audio/Video 

Attachment Text=Press the ID button on the keypad four times 

[Device Settings] 
Failed Response Delay=2000 
20 Hostlnfo=HEX 

[Commands] 
LED) On=4,255 
LED I Off=4,0 
25 Set LED) LeveM,%LED One Level% 
Set Config Params=4, w Setup , \$0D,$0A 

[Events] 

Key) Press=10,l 
30 LED) Off=4,?,0 
Re)ease=)0,0 

Setup Complete- 1 0,"Setup Completed!" 
[Variable Definition] 
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level LED One Level=0.{0,255} 
state JCON-'OFF, {'ONVOFF} 

[Variable Get] 
5 !CON[ON]=5,?,?,255 
!CON(OFF]=5,?.? f 0 

LED One Level=4,?,%LED One Lcvel% 
Button Pushed=10,%Button Pushed% 

10 [Variable Put] 

LED Two Lever=5,%LED One Level% 

[Initialization] 

Init l=Set Config Params 

15 

It may be seen that the configuration file may be divided into sections by section headings for easy 
human readability. The format in which the information is presented is !abel=data, where the label follows 
a generally predetermined form and indicates what information follows the equal sign. The order in which 
the information is presented is not fixed. Therefore, the "Commands" section may come before "Device 

20 information", and the "Device Num" may come before "Mfg Num", for example. 

The first section, Device Information, provides data on the make and model of the device, as well 
as a version number of the configuration file. The "Hardware name" label is used to provide the name of the 
device used for the unattached hardware list. The "Mfg Num" and "Device Num" are unique identifications 
used to identify the maker and model of the device. The "Toolbar Icon" file, Toolbar! con.bmp provides an 

25 icon to be used to represent the unattached hardware device on the tool bar. Additional icon bitmaps, 
Activelcon.bmp and Inactivelcon.bmp, may also be provided for additional display functionalities. The 
"Toolbar Location" label provides a location on the tool bar to locate the device icon. "Attachment Text" is 
the text that will be displayed on the screen providing a brief instruction on how to bring the device on-line. 
The second section, Device Settings, provides information on communication with the device. For 

30 example, the "Failed Response Delay" provides the number of milliseconds to wait for a response if failure 
occurred. "Host Info" provides hexadecimal, decimal, or ASCII formats to display raw device or version 
information available from the device. Other device settings may provide the number of retries for a failed 
command and other functions. 
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The next section, Commands, provides a list of commands that the device may be instructed to cany 
out. For example, turning on or off an LED, as in the example set forth above. In the example provided 
above, the first number preceding the comma after the equal sign is a function number for the PHASTLink® 
and PHASTLink® protocol. The Commands section may also set forth the formats for command responses. 
FIGURES 6A-6F provides exemplary command setup windows that are displayed by installation software 
102 (FIGURE 3) using the command list in the configuration file. The list of commands displayed in the 
window is the collection of commands in the Commands section, which are located on the left side of the 
equal signs. The data on the right side of the equal signs are what is actually sent to the device when the 
corresponding command is selected. Further, the data on the right side of the equal sign further provide 
information on whether the command requires a state variable, text variable or level variable. It may be seen 
from FIGURES 6A-6F, that the command windows prompt for the setting of these variables. 

The Events section describes events that occur in the device that are used to trigger something else. 
For example, "Key! Press" is an event on the device that is monitored. If this happens, then the data on the 
right side of the equal sign is sent to master controller 36. Master controller 36 may then send commands 
to other devices in the system in response to being notified of this trigger event 

The next section provide for Variable Definition of variables. The variable definition takes the form: 
Type VarName^In itial Value, {Range} .Property. The variable type may be boolean, number, level, state, or 
string. VarName is the text name of the variable, which is displayed in all dialog windows that refer to the 
variable. In itial Value is the value of the variable before any initialization occurs. The Range setting 
provides the range of values the variable may be set to. Property is any special property of the variable, 
which may be of the following: 



Property 


Parameters 


Description 


ASCII 


None 


Converts the variable from ASCII data 


MAX 


Num 


Sets the maximum number of bytes to extract or 
compare 


PAD 


None 


Pads the data with leading zeros 


PROMPT 


None 


Prompts the programmer for the value in a command 


DELIM 


Char 


Sets the delimiter for the end of the string or value 


CHKSUM 


Num 


Checksums the data starting at byte number Num 
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In the example above, the variable type is level, the variable name is "LED One Level", the initial value is 
zero (0), and the range is between 0 and 255, inclusive. 

The Variable Get section looks for matches in the input data in the same format as command output 
and sets the value of the variables accordingly. The Variable Put section is used to update a device when 
5 installation software 1 02 sets or changes a variable. The label is the name of the variable that changed, and 
the data that follows after the equal sign is the command required to update the device. The Initialization 
section is used to initialize the device and may be omitted if the device includes firmware that implements 
the initialization process. 

Another section, Conditionals, are associated with the state variables defined for the device. The 
10 following variable types have the corresponding conditionals: 



Variable Type 


Conditionals 


Boolean 


If the variable is true or false 


Level 


If the variable is greater than, less than or equal to a specific 
value 


State 


If the variable is equal to: combo box of states 


String 


None 


List 


None 



Exemplary conditional dialog windows in the installation software programming window are shown in 

20 FIGURES 7A-7C. 

Included in the Appendix are an exemplary class declaration of the generic device interface object, 
an exemplary variable list, an exemplary command list, and an exemplary event list. 

It may be seen that, with the use of configuration files, the size of device interface object and 
installation software is not changed. The small size of the configuration files also enable them to be 

25 embedded into memory (e.g. read only memory) in the device for quick upload to the master controller when 
the device is brought on-line. Further, the process by which the devices may be installed is sufficiently 
flexible to allow either the insertion of the hardware device first or the configuring of the device interface 
object first and then attach them to one another. In addition, instead of the typical six month development 
time required to code a device driver for a new device, it now takes a matter of one or two days to fully 

30 implement the device configuration file. 
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Although several embodiments of the present invention and its advantages have been described in 
detail, it should be understood that mutations, changes, substitutions, transformations, modifications, 
variations, and alterations can be made therein without departing from the teachings of the present invention, 
the spirit and scope of the invention being set forth by the appended claims. 
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APPENDIX 

CLASS DECLARATION 



//- 

5 //Description: Class declaration for the generic device interface module 

#ifhdef_P3GENMOD_H_ 
^define _P3GENMOD_H_ 

10 

#ifadefMCU_68000 

^include "..\basemod\basemod.h" 
^include v *..V.\homeserv\attchman.h n 

#else 

1 5 ^include "VMCUXModulesXbasemodNbasemodii" 

# include w \MCU\horneserv\attchman.)r 

Uend'iT 

//include n P3CommandListJr 
20 ^include "P31nitCommandList.h n 

^include w P3EventLisLh" 

#inchide "P3VariableListfT 

^include w P3SwitcherInfoList.h w 

^include "P3VariableGetLisLh" 
25 ^include n P3GenConstantsJ)" 

^include w P30utGoingCommandLisUT 



// Classes that will be declared 
30 class CP3GenModObject; 
class CP3GenModType; 



const int DEFAULTGENMOD WIDTH =30; 
35 const int DEFAULTGENMODHEJGHT =30; 



// Type Definitions 

typedef CPaGenModObject* LPP3GenModObject; 
40 typedef CP3GenModType* LPP3GenModType; 

extern LPP3GenModType lpP3GenWodTypeMan; 

//„ 

45 //CP3GenModObject 
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class CP3GenModObject : public PHASTObjcct 
I 

public: 

LPP3CommandList pCommandList; 

private: 

DWORD dwAttacMD; 
DWORD dwDeviceJD; 



1 0 //Device 1 nformation 

CString cManufacturer; 

CString cDeviceName; 

CString cHardwareName; 

CString cAttachroentText; 
1 5 DWORD dwManufacturerNumber; 

DWORD dwDeviceNumber, 

CString strActiveBmpFile; 

CString strinactiveBmpFtle; 

20 //Device Settings 

eDisplayType eDisplay; 

DWORD dwP3MessageSendDeJayTimerLength; 
DWORD dwP3MessageRetryTimerLength; 
DWORD dwRetryCount; 
25 DWORD dwMAXRetryCount; 



//Commands/events/conditionals 

30 LPP3ResponseList pResponseLisl; 

LPP3EventList pEventList; 
LPP3SwitcherInfoList pSwitcherlnfo; 
LPP31njtCommandList plnitCommandsList; 

35 BOOL bHasEvents; 

BOOL bHasCommands; 
BOOL bHasConditional; 

BOOL bReadyToSendCommand; 
40 LPP3ResponseNode pCurrentCommandResponseNode; 

//Variable 

LPP3VariableList pVariableList; 

LPP3 VariableGetList pP3VariableGetList; 



45 



LPOutgoingCommandList pOutgoingCommandList; 
LPP3CommandList pVariablePutList; 
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public: 

CP3GenModObject(DWORD dwDevicelD, long IParentMapID. long IParentRoomID, long 
IParentProgrammingObjectID, long 1 System ItemlD, long Manufacturer! D, long IModelJD); 

5 

CP3GenModObjcct(DWORD dwLength, LPBYTE pbBuffer); 

~CP3GenModObject(); 

10 CBaseList ObjectList; 

CBaseList SyncObjectLisl; 

void InitializeData(long ISysItemlD); 
1 5 void BuildObjects(CString &); 

DWORD GetPNETTypeO; 

void FormatCommandString(DWORD &Length,LPBYTE pBuffer, DWORD dwLength, 
LPBYTE IpData, const LPP3CommandNode ApCommandNode); 
void SetupModuleInfo(CString strParamaters); 

20 

LPP3SwitcherInfoList GetSwitcherPti(); 



//Device specific methods: 
25 /♦virtual*/ void Delete^ 

// General methods: 
tfifhdefMCU 

/♦virtual*/ HBITMAP GetBitmap(); 
30 /*virtual*/ void GetBitmaps(HBlTMAP&, HB1TMAP&, long, CRectA); 

/♦virtual*/ void LaunchPropertiesDialog(); 

DWORD GetAudioZoneID0{return NULL; }; 

flendif 

/♦virtual*/ LPPHASTObjectType GetType{); 

35 

// Programming methods: 
flifhdefMCU 

/♦virtual*/ CBaseCommandDlg * NewCommandWindow(CWnd ♦); 

/♦virtual^/ CBaseConditionalDIg ♦ NewConditionalWindow(CWnd ♦); 
40 /♦virtual*/ BOOL HasCommandWindowO; 

/♦virtual*/ BOOL HasConditional Window(); 

/♦virtualV BOOL HasEventsWindowQ {return FALSE; }; 

/♦virtual^/ CString GetFunctionDescription(DWORD, DWORD, LPBYTE); 

/♦virtual*/ CString GetFunctionEngraving(DWORD, DWORD, LPBYTE); 
45 /♦virtual^/ CString GetConditionalDescription(DWORD, DWORD, LPBYTE); 

/♦virtual*/ CString GetEventDesc(long eventID); 
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40 



IpData); 
IpData); 
dataj; 
flendif 



CString GetOutBoundPacketDescription(DWORD dwLength, LPBYTE 
CString GeljnBoundPackelDescription(DWORD dwLength, LPBYTE 
void AddCharFromHex(BYTE *buf^ DWORD &dwLength_, BYTE 



/♦virtual*/ BOOL EvaliiateConditional(DWORD, DWORD, LPBYTE); 
1 0 /♦virtual*/ int GetNumEvents(); 

/♦virtual*/ void GetEvents(!ong *pEventlDs); 

//Network methods: 
/♦virtual*/ DWORD GetSerialSizeO; 
1 5 /*virtualV void Senalize(LPBYTE); 

/♦virtual*/ void Deserialize(DWORD, LPBYTE); 
/♦virtual^/ void HardwareNotify(BOOL); 

CString CreateString(const LPBYTE &pbBuffer, DWORD &dwPos); 
20 DWORD InsertVariablelnCommand(DWORD &Length, LPBYTE 

pBuffer, DWORD dwVarValue, DWORD dwVarPos, const LPP3VariableNode pNode); 

void SendNextCommandO; 
void RemoveCommandFromListO; 
25 void TimerCallBack (DWORD timerlD); 

void AddToSendBuffer(DWORD dwPriority, DWORD dwLength, 
LPBYTE pBuffer, LPP3CommandNode pCommandNode); 



30 

// Attachment methods: 

/♦virtualV void Fil(Attachments(); 

/♦virtual*/ void UnAttachObjectNow(DWORD); 

/♦virtual/ DWORD Attach(DWORD dwObjectlD, DWORD dwAttachType, DWORD 
35 dwAttachFlags); 

/♦virtual/ DWORD AttachFunction(DWORD dwObjectlD, DWORD dwAttachID, DWORD 
dwFunctionID, DWORD dwLength, LPBYTE IpData); 

/♦virtual*/ void DataIn(DWORD dwLength, LPBYTE IpData); 



#ifndefMCU_68000 
#endif 



//probably not need in MCU 
45 BOOL lsAudk>Attached(DWORD dwObjectlD); 

// System Created Variables 

// 
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// void RegisterVariabIes(); 

// void RenameVariabJesO; - 
void Delete VariablesO; 

/* virtual*/ CString GetVariab!eName{int nType); 
5 /^virtual*/ void VariableChanged(BYTE *pNewValue); 

/♦virtual*/ void GetConnections (CBaseList&); 
// /*virtual*/ void Check VariablesO; 

// /*virtual*/ void SetDeviceName (CString cDeviceName_); 
10 private: 

DWORD dwDataStringLength; 



DWORD ParseObjectForDWORD(const CString & strParam, const CString & strKey); 
1 5 CString ParseObjectForString(const CString & strParam, const CString & strKey); 



}; 

20 typedef CP3GenModObject * LPP3GenModObject; 



//- 



//CP3GenModType 

25 class CP3GenModType : public PHASTObjectType 
{ 

public: 

CP3GenModTypeO; 
-CP3GenModTypc0; 

30 

tfifhdefMCU 

/♦virtual*/ int GetBitmaplD(); 
/♦virtual*/ int GetToolBarBitmaplDO; 
35 /*virtual*/ int GetToolBarMasklD(); 

/♦virtual*/ HCURSOR GetCursor(); 
/♦virtual*/ HBITMAP GetBitniap(); 

ftmdif 

/♦virtual^/ WORD GetVersionQ; 
40 /♦virtual^/ WORD GetlDQ; 

/♦virtual*/ LPPHASTObject NewObject(long, long, long, long, long, long); 
/♦virtual*/ LPPHASTObject NewObject(DWORD, LPBYTE); 
/*virtual*/ void DeletePHASTObject(LPPHASTObject); 

}; 

45 

#endif 
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VARIABLE LIST 



//File: GenComboObjectListh 

// Purpose: Declare node types Contact, Relay, IR and Serial. 
5 // 

// PHAST(c)1999 

#ifndef_CP3VARIABLELIST_H_ 
tfdefine _CP3VARIABLELIST_H_ 

10 

#ifndefMCU 68000 
^include "..V.WHomeServXAttchman h° 
//include " AAXHomeSenABaseList JT 
15 #else 

//include "\MCU\HomeServ\Attchman.h* 
^include "\MCU\Homeserv\BaseList.h" 
#endif 

20 //include ^\AHomeselv\VariableManage^.h ,, 
class CP3GenModObject; 

//- 

25 //CP3VariableNode 

class CP3VariabIeNode : public CBaseNode 

V < 
public: 



30 



DWORD dwVariableType; 
DWORD dwVarlD; 



35 



40 



BOOLbHidden; 
BOOL bASCH; 
DWORD dwMaxBytes; 
char chDelim; 
BOOL bConfigPage; 
BOOLbPromptUser, 
BOOLbPad; 

DWORD dwChecksumStart; 
int MinRange; 
int MaxRange; 



45 



// 



LPVariablePut IpVariablePut; 
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public: 

CP3Variab!eNode(); 

CP3 VariableNode(DWORD dwLength, LPBYTE pBuffer); 

5 // CP3 VariableNode(DWORD dwVariableSystemlD, DWORD dwVariableType, BOOL bAscii, 
DWORD dwMaxBytes, 

// char chDelim, BOOL bConfigPage, BOOL bPromptUser, BOOL bPad, 

// DWORD dwChecksumStart/*, LPVariablePut IpVariablePut*/, BOOL bHidden); 

10 ~CP3VariableNode()0; 

CString GetVariableNameO; 

DWORD ScaleLevelValue(DWORDdwVaiue); 

1 5 WORD ParseSerialString (CString clnput, LPBYTE pOutput, int maxOutputLen); // <- 

call this externally 

void SetVariableVaIue(DWORD varlD, DWORD dwVarValue); 

DWORD GetVarValueFromDataIN(DWORD dwLength, LPBYTE IpTempData, DWORD 
dwVariablePos); 



20 



25 



/♦virtual*/ DWORD GetSerialSizeO; 
/♦virtual*/ void Serialize(LPBYTE); 
/♦virtual^ void Deserialize(DWORD, LPBYTE); 

}; 



typedef CP3VariableNode^ LPP3VariableNode; 



30 li- 



lt CXSerialCommandList 

class CP3VariableList r public CBaseList 
{ 

35 

int nPos; 
CString cString; 
// CString cDeviceName; 

40 CP3GenModObject ♦ pGenModObject; 

lie: 

CP3VariableListO; 

45 

CString Parse Variables(CString cString); 
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CP3VariableNode ♦ GetNodeByVariabIeName(CString); 
CP3VariableNode ♦ GetNodeByVariablelD(DWORD); 

//variable parsing functions 

LPLevelVariable GetLevelVariabJeInfo(CString cVarNameStr, LPP3 VariableNode 

pTempP3Var); 

LPNumberVariable GetNumberVariable1nfo(CString _cVarNameStr); 
LPBoolean Variable GetBoolVariablelnfo(CString _cVarNameStr); 
int GetNumberInParen(CString _cTempString); 
void SetVariableParams(LPP3Variab)eNode IpTempVariableNode); 
CString GetQuotedTextStringO; 

LPEnumeratedVariable GelState Variable! nfo(CString _cState VarNameStr); 
CString GetVariableNameO; 
DWORD GetVaribleType(); 

/♦virtual*/ DWORD GetSerialSize<); 
/♦virtual*/ void Serialize(LPBYTE); 
/♦virtual*/ void Deserialize(DWORD ? LPBYTE); 



}; 



typedef CP3VariableList* LPP3VariabIeList; 
tfendif 
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COMMAND LIST 

// File: GenComboObjectList.h 

// Purpose: Declare node types Contact, Relay, IR and Serial. 
5 If 

// PHAST(c)1999 



#ifndef_CP3COMMANDLIST_H_ 
1 0 tfdefine _CP3COMMANDLIST_H_ 



#ifhdefMCU_68000 
include *..\..\\HomeServ\Attchman.h w 
1 5 ^include ^ ASoftCntc\SoftCntc Ji" 

#inchide w ..\.A\HomeServVBaseList.h" 
#else 

#include B \MCU\HomeServVAttchman.h n 
include , ^MCU\Modules\SoftCntc\SoftCntc.h ,, 
20 #include "\MCU\Homeserv\BaseList.h w 
tfendif 

include "P3VariableListJb B 
include "CZOMSt^ing.h , • 
25 include T3CommandVariableListh" 



//- 

// CP3ResponseNode 

30 

class CP3ResponseNode : public CBaseNode 
{ 

public: 

35 DWORD dwFunctionlD; 

DWORD dwMessageTypelD; 
LPZOMString lpResponseData; 
LPCommandVariableList lpCommandVarList; 

40 public: 

CP3ResponseNode(DWORD_dwMessageType]D, BYTE * _pResponseDala, 
LPCommandVariableList _pTempCommandVariableList, 
DWORD dwFunctionlD, int nLength); 

45 BOOL CompareResponseData(DWORD dwLenglh, LPBYTE IpData), 

CP3ResponseNodeO; 
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~CP3ResponseNode(); 

DWORD GetSerialSizeO; 
void Serialize(LPBYTE pBuffer); 
5 void Deserialize(DWORD dwLength, BYTE ♦ pBuffer); 

}; 

typedef CP3ResponseNodc * LPP3RcsponseNode; 

10 

//- 

// CP3CommandNodc 

class CP3ResponseList : public CBaseList 
15 { 

public: 

CP3ResponseList(); 
~CP3ResponseList(){} ; 

20 

DWORD GetSerialSizeO; 

void Serialize(LPBYTE pBuffer); 

void Deserialize(DWORD dwLength, BYTE * pbBufTer); 

25 }; 

typedef CP3ResponseList * LPP3ResponseList; 



30 // 

// CP3CommandNode 

class CP3CommandNode : public CBaseNode 
{ 

35 public: 

// DWORD dwNodelD; 

DWORD dwFunctionID; 
BOOLbHidden; 
40 DWORD dwMessageTypelD; 

LPZOMString IpCommandData; 
LPCommandVariableList IpCommandVarList; 
CP3ResponseNode *lpResponse; 

45 

public: 
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5 



10 



CP3CommandNode<CStting_cCommandName, DWORD _dwMessageTypelD, BYTE * 
cCommandData, 

LPCommandVariableList_pTempCommandVariableList, 
BOOL bHidden, DWORD dwFunctionID, int nLength); 

CP3CommandNode<); 
~CP3CommandNode(); 



WORD ParseSerialString (CString clnput, LPBYTE pOutput, int maxOutputLen); // <- 
call this externally 



DWORD GetSeriaJSizeO; 
1 5 void Seriali2e(LPBYTE pBuffer); 

void Deserializer WORD dwLength, BYTE * pBuffer); 

>; 

20 typedef CP3CommandNode ♦LPP3CommandNode; 



//- 



25 



// CXSerialCommandList 

class CP3CommandList : public CBaseList 
{ 

DWORD NextCoromandID; 



30 public: 

CP3CommandList(); 
-CP3CommandListO{}; 

35 DWORD GetNextFunctionlDO; 

BOOL ParseCommands< CString cString, LPP3ResponseList IpResponseList, const 
LPP3VariableList cVarList); 

40 int ASCHHexTolnt(CString _cHexChar); 

CString GetCommandNaine(const CString AcString, int &_nPos); 



45 



LPP3CoramandNode GetNodeByCommandName(CString); 

void SetupVariables(LPP3VariableList pVariableList, LPP3ResponseList pResposneList); 

DWORD GetSerialSizeO; 

void Serialize(LPBYTE pBuffer); 
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}; 

typedef CP3CommandList * LPP3CommandList; 
#cndif 
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EVENT LIST 

// File: GenComboObjectList.h 

// Purpose: Declare node types Contact, Relay, IR and Serial. 
5 // 

// PHAST(c)1999 



#irhdef _CP3EVENTLIST_H_ 
10 fldefine _CP3EVENTLIST_H_ 



#ifndefMCU_68000 
^include "..\.A\HomeServ\Attchman.h" 
1 5 include \ A.A\HomeServ\BaseList.h" 
#else 

^include "\MCU\HomeServ\Anchman.h'* 
^include "\MCU\Homeserv\BaseList.h" 
#endif 

20 

include "CZOMString.h" 

//. 

//CP3EventNode 

25 

class CP3EventNode : public CBaseNode 
{ 

public: 

30 DWORD dwEventID; 

int nMessageTypelD; 
LPZOMString IpEventData; 

public: 

35 CP3EventNode(); 

CP3EventNode(DWORD dwLength, LPBYTE pbBuffer); 

CP3EverrtNode(CString _cEventName, DWORD _dwEventlD, BYTE ♦ _pEventData, int 
nLength, int nMessageTypelD); 
40 ~CP3EventNode(); 

DWORD GetSerialSizeO; 

void Serialize(LPBYTE pBuffer); 

void Deserialize(DWORD dwLength, BYTE * pbBufTer); 

45 

private: 
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}; 

typedef CP3EventNode« LPP3EventNode; 



class CP3EventList : public CBaseList 
{ 

10 DWORD dwNextEventID; 

public: 

CP3EventListO; 
15 -CP3EventList(); 

CString ParseEvents(CString cString, DWORD dwObjectlD); 

LPP3EventNode GetNodeByEventName(CString); 
20 LPP3EventNode GetNodeByEventID(DWORD); 

DWORD GetNextEventID(); 

CString GetEventName(CString AcString, int &nPos); 
int ASCHHexToInt(CString _cHexChar); 

void CompareEvcnt(DWORD dwLcngth,LPBYTE IpData, DWORD ObjectID); 



25 



30 



35 



DWORD GetSerialSizeO; 

void Serialize(LPBYTE pBuffer); 

void Deserialize(DWORD dwLcngth, BYTE * pbBufler); 

}; 

typedef CP3EventList* LPP3EventList; 
tendiT 
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WHAT IS CLAIMED IS : 

I . A control system, comprising: 
a master controller, 

at least one device coupled to the master controller via a network; 
5 at least one generic device interface module residing on the master controller, the at least one 

device interface module defining a basic protocol for interface with any device; and 

configuration information associated with the at least one device being operable to tailor the at 
least one generic device interface module to communicate and operate with the at least one device. 

10 2. The control system, as set forth in claim 1 , further comprising at least one instance of the 

at least one generic device interface object residing on the master controller and having die configuration 
information associated with the at least one device. 

3. The control system, as set forth in claim 1, wherein the configuration information is 
15 described in a configuration file residing in the master controller. 

4. The control system, as set forth in claim I, wherein the configuration information is 
described in a configuration file residing in a data storage device accessible by the master controller. 

20 5. The control system, as set forth in claim 1, wherein the configuration information is 

described in a configuration file residing in the at least one device, the configuration file being 
uploadable to the master controller. 

6. The control system, as set forth in claim 1, wherein the configuration information 
25 comprises information related to the manufacturer and model of the at least one device. 

7. The control system, as set forth in claim 1, wherein the configuration information 
comprises a unique manufacturer number representative of the at least one device manufacturer and a 
unique device number representative of the model of the at least one device. 

30 
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8. The control system, as set forth in claim I , further comprising a display coupled to the 
master controller, wherein the configuration information comprises data related to the display 
representation of the at least one device on the display. 

9. The control system, as set forth in claim 1, further comprising a display coupled to the 
master controller, wherein the configuration information comprises a bitmap file of an icon 
representation of the at least one device. 

10. The control system, as set forth in claim 1 , wherein the configuration information 
comprises a definition of commands and format which the at least one device is responsive to. 

1 1 . The control system, as set forth in claim 1, wherein the configuration information 
comprises a definition of variables and format which the at least one device is responsive to. 

12. The control system, as set forth in claim ] , wherein the configuration information 
comprises a definition of events and format which the at least one device is responsive to. 

13. A method of communicating with a device in a control area network, comprising: 
automatically obtaining configuration information associated with the device, the configuration 

file including communication and operating protocol of the device; 

instantiate a specific instance of a generic device interface object using the configuration 
information associated with the device; and 

communicating with the device via the specific object instance. 

14. The method, as set forth in claim 13, further comprising: 
connecting the device to the control area network; and 

uploading the configuration information from the device via the control area network. 

1 5. The method, as set forth in claim 1 3, further comprising: 
connecting the device to the control area network; 

obtaining version information associated with configuration information in the device; 
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comparing the obtained version information and version information associated with 
configuration information available at a master controller; and 

uploading the configuration information from the device via the control area network in response 
to the configuration information therein having a later version. 

5 

1 6. The method, as set forth in claim 1 3, further comprising: 
displaying a software icon representative of the specific object instance; 
displaying a device icon representative of the device; and 
associating the software icon and device icon with one another. 

10 

1 7. The method, as set forth in claim 13, wherein automatically obtaining configuration 
information further comprises reading a configuration file having device information related to the 
device. 

IS 18. The method, as set forth in claim 1 7, wherein reading the configuration file comprises 

reading a unique manufacturer number and a unique device number associated with the device. 

19. The method, as set forth in claim 17, wherein reading the configuration file comprises 
reading an icon bit map file associated with the device. 

20 

20. The method, as set forth in claim 1 7, wherein reading the configuration file comprises 
reading a version number associated with the configuration file. 

21 . The method, as set forth in claim 17, wherein reading the configuration file comprises 
25 reading display information associated with the device. 

22. The method, as set forth in claim 13, wherein automatically obtaining configuration 
information further comprises reading a configuration file defining commands operable to be performed 
by the device. 

30 

23. The method, as set forth in claim 1 3, wherein automatically obtaining configuration 
information further comprises reading a configuration file defining events that may occur at the device 
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and the corresponding data to be generated by the device and sent over the control area network in 
response to the occurrence of the event. 

24. The method, as set forth in claim 13, wherein automatically obtaining configuration 

5 information further comprises reading a configuration file defining variables associated with operations 
of the device. 

25. A control area network, comprising: 
a master controller; 

1 0 at least one device coupled to the master controller via a local area network; 

at least one generic device interface object residing on the master controller, the at least one 
device interface object defining a basic protocol for interface with any device; and 

a configuration file associated with the at least one device being operable to tailor the at least one 
generic device interface object to generate a specific interface object instance operable to communicate 
1 5 and operate with the at least one device. 

26. The control area network, as set forth in claim 25, wherein the configuration file resides 
in the master controller. 

20 27. The control area network, as set forth in claim 25, wherein the configuration file resides 

in a data storage device accessible by the master controller. 

28. The control area network, as set forth in claim 25, wherein the configuration file resides 
in the at least one device, the configuration file being uploadable to the master controller. 

25 

29. The control area network, as set forth in claim 25, wherein the configuration information 
comprises information related to the manufacturer and model of the at least one device. 

30. The control area network, as set forth in claim 25, wherein the configuration file 

30 comprises a unique manufacturer number representative of the at least one device manufacturer and a 
unique device number representative of the model of the at least one device. 
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3 1 . The control area network, as set forth in claim 25, further comprising a display coupled 
to the master controller, wherein the configuration file comprises data related to the display 
representation of the at least one device on the display. 

32. The control area network, as set forth in claim 25, further comprising a display coupled 
to the master controller, wherein the configuration file comprises a bitmap file of an icon representation 
of the at least one device. 

33. The control area network, as set forth in claim 25, wherein the configuration file 
comprises a definition of commands and format which the at least one device is responsive to. 

34. The control area network, as set forth in claim 25, wherein the configuration file 
comprises a definition of variables and format which the at least one device is responsive to. 

35. The control area network, as set forth in claim 25, wherein the configuration file 
comprises a definition of events and format which the at least one device is responsive to. 
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